home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP050392.ARJ / 05-03-92.TPC
Text File  |  1992-05-03  |  64KB  |  1,952 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       01-01-00 00:00:00
  6. From       
  7. To         
  8. Subject    
  9.  
  10.  
  11. --- WM v2.01/92-0100
  12.  * Origin: A.C.E. of Spades (615)383-4381 The B.A.N. board (1:116/33)
  13.  * Tossed by SFToss v1.00b on 92/04/09  12:01:00
  14.  
  15. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  16.  
  17. Conference 4
  18. Date       04-26-92 05:02:05
  19. From       Trevor Carlsen
  20. To         Matt Heck
  21. Subject    Re: turbo pascal/turbo pascal profession
  22.  
  23.  
  24.  
  25.  MH> Say, that IS useful... is there anything out now that is similar to 
  26.  MH> the execution profiler?
  27.  
  28. The execution profiler is exceedingly useful when finetuning a program,especiall
  29.  when in the final stages  of development.
  30.  
  31. Apart from the one that comes in the Professional package, there is another
  32. (the same one I think) in Borland's Turbo Debugger and Tools package and Turbo
  33. Power also market one in their Turbo Analyst package.
  34.  
  35. TeeCee
  36.  
  37. --- TC-ED   v2.01  
  38.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  39.  * Tossed by SFToss v1.00b on 92/04/26  16:02:14
  40.  
  41. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  42.  
  43. Conference 4
  44. Date       04-26-92 05:07:00
  45. From       Trevor Carlsen
  46. To         Michael Stillwell
  47. Subject    Strings
  48.  
  49.  
  50.  
  51.  MS> Is there some super duper way to create a string 
  52.  MS> consisting of spaces?
  53.  
  54. procedure FillString(var st: string; len: byte; ch: char);
  55.   begin
  56.     st[0] := char(len);
  57.     FillChar(st[1],pred(len),ch);
  58.   end;
  59.  
  60. You would be well advised to find Eagle Software excellent shareware package
  61. strg61a.* file and download it.  It has a lot of very useful string routines
  62. in it.  The registered version is even better.
  63.  
  64. TeeCee
  65.   
  66.  
  67. --- TC-ED   v2.01  
  68.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  69.  * Tossed by SFToss v1.00b on 92/04/26  16:02:14
  70.  
  71. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  72.  
  73. Conference 4
  74. Date       04-26-92 05:31:38
  75. From       Trevor Carlsen
  76. To         Shelby Crane
  77. Subject    Re: Just some questions...
  78.  
  79.  
  80.  
  81.  SC> One, if you have a statement such as 'I want to go home.' How
  82.  SC> would you use the pos function to return the position of the
  83.  SC> SECOND 't'... I always get the first 't' in want...
  84.  
  85. The best way is to find a copy of Eagle Software's strg61a.* package and use
  86. the StrPos* function.  It is fast and suitable.  Otherwise -
  87.  
  88. function StrPos(var st: string; ch: char; nth: byte);
  89.   var
  90.     count,x : byte;  
  91.   begin
  92.     count := 0;
  93.     x     := 0;
  94.     while (x < length(st)) and (count < nth) do begin
  95.       inc(x);
  96.       if st[x] = ch then inc(count);
  97.     end;
  98.     StrPos := count;
  99.   end;
  100.  
  101. Untested... this is really the ideal sort of thing for assembler.
  102.  
  103. TeeCee
  104.  
  105. --- TC-ED   v2.01  
  106.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  107.  * Tossed by SFToss v1.00b on 92/04/26  16:02:15
  108.  
  109. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  110.  
  111. Conference 4
  112. Date       04-26-92 05:41:59
  113. From       Trevor Carlsen
  114. To         John Gohde
  115. Subject    What Else On Tp
  116.  
  117.  
  118.  
  119.  JG> No, I wrote it used to be simple.
  120.  
  121.  > *[TP] is a great language and it is simple to learn too.  I think it
  122.  > *always has been and always will be.  I really can't foresee how the
  123.  > *addition of things such as Turbo Vision etc... could make the PASCAL
  124.  > *language more complicated.  It is what it was and it was what it is.
  125.  > *If someone wants to learn
  126.  
  127.  JG> Sure! I consider your reply to be a typical emotional response to
  128.  JG> any criticism of Borland.
  129.  
  130.  JG> I think that  the ideal simple  TP was somewhere  between version
  131.  JG> 4.0 and  version 5.0. Version  4.0 enhanced with  third party DOS
  132.  JG> functions is quite simple and workable (for a new user).
  133.  
  134. Try as I might, I fail to see where or how that reply could be construed as
  135. "emotional".  I would have called it factual.
  136.  
  137. Your criticism of recent versions is not based on facts.  TP6 is no more complex
  138. than TP4 except for the addition of three additional reserved words to cover
  139. the use of OOP.  Hardly a big difference.  
  140.  
  141. You cannot *reasonably* include TV or OOP as justification for saying the
  142. language is more complex for a beginner as firstly, TV is not part of the
  143. language and secondly, OOP does not have to be used or learnt in order to
  144. use the language in almost exactly the same way as you would have with TP4.
  145.  
  146. What Borland have done is to increase the usefulness and power for the power
  147. user without affecting one zot how a beginner needs to approach his task.
  148.  
  149. And your statements on SBP+ need some clarification.  Can object files created
  150. for C libraries be linked *unchanged* into SBP+ compiled programs?  I think
  151. not, but I could be wrong.  The reason I say this is because Pascal and C
  152. have different calling conventions.  If SB have solved that problem I applaud them.
  153.  
  154.  
  155. TeeCee
  156.  
  157. --- TC-ED   v2.01  
  158.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  159.  * Tossed by SFToss v1.00b on 92/04/26  16:02:15
  160.  
  161. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  162.  
  163. Conference 4
  164. Date       04-26-92 05:58:14
  165. From       Trevor Carlsen
  166. To         John Gohde
  167. Subject    Features Lacking In Tp
  168.  
  169.  
  170.  
  171.  JG> Well, we have  been over this before. Everyone  has their own pet
  172.  JG> wants.  For,  me  the  most   serious  problem  with  TP  is  its
  173.  JG> restrictive  .OBJ limitations.  What you  can link  to TP is too
  174.  JG> restrictive. It would be nice to  be able to link C Library .OBJs
  175.  JG> directly to  TP (as you  can with SBP+).  But, not being  able to
  176.  JG> link  TP via  an .OBJ  file to  fourth generation  languages like
  177.  JG> DBase   and   other   languages   definitely   classifies  TP  as
  178.  JG> mickey-mouse, in my book.
  179.  
  180. You are entitled to that opinion.  I presume it means that you use SBP+ and
  181. not TP.  However I would swear that I saw a message from you somewhere in
  182. the past that you were using the mickey-mouse language.  If you do not like
  183. something you should not buy it. By buying it you are being counter productive
  184. or even perhaps hypocritical.  A  Market place flop is the surest possible
  185. way to get the message across to big companies and I believe that Borland
  186. would be no exception to this.
  187.  
  188. I believe that TP is by no means perfect.  I consider it to be so far in front
  189. of whatever comes second to be almost a joke, not because of Borland but because
  190. no other company has delivered much needed competition yet. Twelve months
  191. ago I wrote to SB requesting more information on SBP+.  They ignored me. A
  192. second letter six months later has also been ignored.  Hardly what I would
  193. call engendering confidence in a potential customer. Scott Samet's (or was
  194. it Scott Sanbar) experience with them would tend to suggest that my experience
  195. was not normal for them but it still makes me uneasy about purchasing the
  196. product.
  197.  
  198. John nobody is forcing you to use TP or Borland products.  Go buy something
  199. else and use that. Discussion on them will be just as welcome here, if not
  200. more so, as it will broaden our outlook and, hopefully, better inform us for
  201. future purchasing decisions.  However in order to be better informed we need
  202. facts - not hysteria or paranoia.
  203.  
  204. TeeCee
  205.  
  206.  
  207.  
  208. --- TC-ED   v2.01  
  209.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  210.  * Tossed by SFToss v1.00b on 92/04/26  16:02:15
  211.  
  212. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  213.  
  214. Conference 4
  215. Date       04-26-92 07:49:08
  216. From       Trevor Carlsen
  217. To         dj Murdoch
  218. Subject    TP6 "bug"
  219.  
  220.  
  221.  
  222. It appears that TP6 does not calibrate the delay procedure correctly when
  223. used with a fast machine - eg a 486/33.  I would assume that Borland would
  224. be aware of this - are you?
  225.  
  226. The problem is quite serious as any programs written using the crt's delay
  227. procedure become nearly unusable if delays are needed and thus every instance
  228. where delay is used needs to be changed and rewritten.  This is something
  229. that I would expect a free fix for and not expect to pay for a fix via an
  230. upgrade.
  231.  
  232. I post Borland's (Pacific) response here after I call them.
  233.  
  234.  
  235. TeeCee
  236.  
  237. --- TC-ED   v2.01  
  238.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  239.  * Tossed by SFToss v1.00b on 92/04/26  16:02:15
  240.  
  241. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  242.  
  243. Conference 4
  244. Date       04-26-92 09:08:44
  245. From       Dj Murdoch
  246. To         Trevor Carlsen
  247. Subject    Re: Help Needed with TP arrays
  248.  
  249.   TC> Actually by declaring the array as large as is possible 
  250.  TC> this cannot happen.  However my view on that method is 
  251.  TC> that it *might* allow a programmer to become complacent 
  252.  TC> about writing range checking routines. By forcing him to 
  253.  TC> turn off automatic range checking, I hope to increase the 
  254.  TC> awareness of the need for code to do it.  Either way the 
  255.  TC> method can be deadly if no RC code is written and there is 
  256.  TC> any possibility of out-of-range values.
  257.  
  258. That attitude seems to me to be exactly backwards.  Most programs have no
  259. range checking at all, because Borland defaults TP to $R-, and most people
  260. can't be bothered to do it manually.  If people did their programming with
  261. $R+ always turned on, fewer bugs would make it out.  
  262.  
  263. If you develop programs with the $R- option set, you deserve all the trouble
  264. you can get when you miss doing one manual range check.
  265.  
  266. --- Msg V3.2
  267.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  268.  * Tossed by SFToss v1.00b on 92/04/27  09:00:49
  269.  
  270. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  271.  
  272. Conference 4
  273. Date       04-26-92 09:22:16
  274. From       Dj Murdoch
  275. To         John Gohde
  276. Subject    Extended character set (was: Dezip)
  277.  
  278.   JG> I tend to agree with you. Here, 99%  of fido users use an IBM PC.
  279.  JG> So it ticks me off frankly  that us IBM users  are not allowed to
  280.  JG> use the  IBM extended character set;  apparently because somebody
  281.  JG> with a toy computer or some nut using an archaic 7-bit main frame
  282.  JG> might not be able to deal with these characters.
  283.  
  284. The extended characters aren't standard around the world.  If you used them,
  285. your messages wouldn't appear the same everywhere.  Since this is an internation
  286. l echo, that's a good enough reason to avoid them.
  287.  
  288. For example, from the current version of my TP bug list (to do my best to
  289. stay on topic):
  290.  
  291. THistory.Draw uses characters 221 and 222 which are not standard outside codepag
  292.  437.
  293.  
  294. (On my machine, 221 and 222 are the thick vertical bars.  In codepage 850,
  295. a multilingual one commonly used in Europe, they're "|" and an accented "i".
  296.  In the Slavic code page 852, they're a block and an accented "T".) 
  297.  
  298.  
  299. --- Msg V3.2
  300.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  301.  * Tossed by SFToss v1.00b on 92/04/27  09:00:49
  302.  
  303. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  304.  
  305. Conference 4
  306. Date       04-26-92 09:49:55
  307. From       Dj Murdoch
  308. To         Scott Sanbar
  309. Subject    Re: TPW patches
  310.  
  311.   SS> I have a file for Turbo Pascal for Windows downloaded off 
  312.  SS> compuserve.  It has a patch for the IDE, various units and 
  313.  SS> library code for OLE, TrueType and MM stuff as well as a 
  314.  SS> new copy of WINDEBUG.DLL so the debugger will work, 
  315.  SS> although not very well :(.  This represents Borlands 
  316.  SS> temporary patchwork for Windows 3.1 I guess until the next 
  317.  SS> upgrade, which will hopefully not be too long.
  318.  
  319.  SS> I got it off compuserve.  If anyone wants it, I will make 
  320.  SS> the 90K .zip available on my boss node for FREQ.
  321.  
  322. Is that TPWN31.ZIP, with files dated 6 April 92?  If so, I "hatched" it to
  323. PDN last week, so it should be available fairly widely by now.  (I don't know
  324. any PDN node except 1:221/177, in case anyone asks.)
  325.  
  326. --- Msg V3.2
  327.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  328.  * Tossed by SFToss v1.00b on 92/04/27  09:00:49
  329.  
  330. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  331.  
  332. Conference 4
  333. Date       04-27-92 09:50:16
  334. From       Trevor Carlsen
  335. To         Jim Starke
  336. Subject    Procedures...
  337.  
  338.  
  339.  
  340.  JS> {Untested Code!}
  341.  JS> Program Test ;
  342.  
  343.  JS> Begin
  344.  JS> If ParamCount <> 3 then begin
  345.  JS>   ClrScr ;
  346.  JS>   WriteLN('To use this program you MUST have 3 arguments to show the');
  347.  JS>   WriteLN('Program what you want it to do!') ;
  348.  JS>   WriteLN('Test -A -B -C') ;
  349.  JS>   Exit ;                       { Wrong Parameter count! Abort! }
  350.  JS> end ;
  351.  JS> ...
  352.  JS> ...  { Program Code here. }
  353.  JS> ...
  354.  JS> End.
  355.  
  356.  JS> Sure, there is a way around using the exit in this program but you 
  357.  JS> would make it a lot less readable (I have been wrong before so I don't 
  358.  
  359.  JS> doubt I may be wrong here.). This way, you keep everything in one spot 
  360.  
  361.  JS> and it is very concise as to what the exit was/is for.  
  362.  
  363. Bad example Jim.  All the above requires to be absolutely readable is the
  364. addition of three words - else begin { Program Code here } end;
  365.  
  366. However I agree with your method here, except that I would use halt not exit.
  367.  
  368. TeeCee
  369.  
  370. --- TC-ED   v2.01  
  371.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  372.  * Tossed by SFToss v1.00b on 92/04/27  18:58:43
  373.  
  374. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  375.  
  376. Conference 4
  377. Date       04-27-92 00:00:04
  378. From       Terry Hughes
  379. To         John Reid
  380. Subject    Sorting records
  381.  
  382.  
  383. JR> It was very similar to the sort that comes with Turbo Power's OPRO, but
  384. JR> the OPRO sort only works if the file fits in memory.
  385.  
  386. JR> Borland no longer sells or supports it, even though the last (TP4)
  387. JR> version works with TP6. You might find a dusty copy in some mail order
  388. JR> house or a private individual might want to sell one. (I'd rather sell my
  389.  
  390. JR> keyboard.) It was about $100 new. Bonus: complete and highly readable
  391. JR> source code was provided.
  392.  
  393. JR> Someone could do the Pascal community a big service by developing an OOP
  394. JR> version of such a universal sort and offering it as shareware.
  395.  
  396. FWIW, our B-Tree Filer product has always included a merge sort
  397. very similar in concept to the sort that Borland included with
  398. its old Database Toolbox -- with the exception that ours is
  399. much faster and is part of current product.
  400.  
  401. Our Windows System Library will include that same sort in
  402. "psuedo OOP" for TPW programmers.
  403.  
  404. -Terry
  405.  
  406.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  407.  
  408. --- Maximus 2.01wb
  409.  * Origin: The Programmers Playhouse (1:128/60)
  410.  * Tossed by SFToss v1.00b on 92/04/28  07:58:37
  411.  
  412. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  413.  
  414. Conference 4
  415. Date       04-27-92 00:00:08
  416. From       Terry Hughes
  417. To         Rene Seguin
  418. Subject    Question, Compression
  419.  
  420.  
  421. RS>      I think that pkZip/ARJ/etc. are all lz78/lzw (dictionary based)
  422. RS>   on +/- 4096 bytes blocks with huffman (redundancy coding) *after*.
  423.  
  424. RS>   It makes no sense to me to make two passes with almost the same thing:
  425. RS>   huffman and Shannon who only differ in the way they build/evaluate
  426. RS>   there trees. As for common archivers, I think they do some statistics
  427. RS>   (probably using boyer-moore) on the stream before the first pass to
  428. RS>   speed thing a bit. Like that, they can bypass some evaluations during
  429. RS>   the real coding and perform some greedy fast hashcoding. And how damn
  430. RS>   fast do they do this!
  431.  
  432. I'm less familar with ZIP and ARJ but LHARC definitely uses a
  433. two-stage compression. The first stage is an LZ sliding
  434. dictionary on the input stream. The output from the sliding
  435. dictionary is fed directly into a Huffman encoder. So, you get
  436. the benefits of a two-stage compression while making only one
  437. pass over the input data.
  438.  
  439. -Terry
  440.  
  441.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  442.  
  443. --- Maximus 2.01wb
  444.  * Origin: The Programmers Playhouse (1:128/60)
  445.  * Tossed by SFToss v1.00b on 92/04/28  07:58:37
  446.  
  447. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  448.  
  449. Conference 4
  450. Date       04-26-92 21:57:00
  451. From       Norbert Igl
  452. To         Ryan Brown
  453. Subject    Printing (to screen) an ANSI array
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  > IMAGEDATA is [1..4000]
  460.  
  461.  > for counter := 1 to 4000 do {counter is integer}
  462.  >   begin
  463.  >     write(IMAGEDATA[counter]);
  464.  >   end;
  465.  
  466.  > etc, etc, etc.eallocations.
  467.  
  468. Fascinating!  How did you do this before Pascal had objects?!  
  469.  
  470.  >As you can see, the memory allocation is a pretty minor part of it.  
  471.  
  472. Was the memory allocation done in "Matrix()"?
  473.  
  474.  >The 
  475.  >dynamic indexing is really ugly (I'd like to use "y[k,j]", but I'm stuck 
  476.  
  477.  >using "y^.r^[k]^.c[j]"), but I haven't found any way around that.
  478.  
  479. Why can't a future Pascal compiler translate "y[k,j]" to "y^.r^[k]^.c[j]"
  480. for you?  I've never used Fortran on a PC, but don't PC Fortran compilers
  481. ermany, Norbert
  482.  
  483. ---
  484.  * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
  485.  * Tossed by SFToss v1.00b on 92/04/28  07:58:45
  486.  
  487. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  488.  
  489. Conference 4
  490. Date       04-27-92 01:08:01
  491. From       Norbert Igl
  492. To         Jason Vaux
  493. Subject    Bits and bytes
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  > NG>Function Bin_2_Long(Bin:string):longint;
  500.  > Thanks Norbert, It works great. Now My boss wants one to got the other
  501.  > way. I need a procedure that take a Byte and turns into a string.
  502.  > Bye from Duncan, British Columbia,
  503.  
  504.    Hi Jason, no problem.... (:-))
  505.  
  506. -------------------------8<---------------------------------
  507.  
  508. function Byte_2_bin (B:Byte):string;
  509. var s : string;
  510.     i : byte;
  511. begin
  512.   s := '';
  513.   for i := 7 downto 0 do           { all possible bit-positions }
  514.     if (B and ( 1 shl i )) > 0     { is this bit set ? }
  515.       then s := s + '1'            { YEAH...}
  516.       else s := s + '0';           { no. }
  517.   Byte_2_bin := s                  { return the value }
  518. end;
  519.  
  520. hmmmm...hey, maybe you need this for WORD and LONGINT also?
  521. before you say no.....here we go...(:-))
  522.  
  523. function Word_2_bin(W:Word):String;
  524. begin
  525.   Word_2_bin := Byte_2_bin( W SHR 8 ) + Byte_2_bin( W and $FF )
  526. end;
  527.  
  528. function Long_2_bin(L:Longint):String;
  529. begin
  530.   Long_2_bin := Word_2_bin( L SHR 16 ) + Word_2_bin( L AND $FFFF )
  531. end;
  532.  
  533. ------------------------->8---------------------------------
  534. Bye from Germany, Norbert
  535.  
  536. ---
  537.  * Origin: not available in non-comercial version. Ask for (2:241/5300.3)
  538.  * Tossed by SFToss v1.00b on 92/04/28  07:58:45
  539.  
  540. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  541.  
  542. Conference 4
  543. Date       04-27-92 08:48:30
  544. From       Dj Murdoch
  545. To         Bob Bannon
  546. Subject    Re: Pointers as function results (was: P
  547.  
  548.   BB> I just read the tail end of your message lamenting the 
  549.  BB> inability to create "matrix-like" variables in TP of the 
  550.  BB> form y[k,j] in the heap.  Can you explain (possibly a 
  551.  BB> repeat of something I missed) the way around that that you 
  552.  BB> allude to?  
  553.  
  554. The simplest way around it is to create a matrix object.  Have it store the
  555. data in whatever way is convenient, and always use methods to access it. 
  556. For example, if your arrays will never exceed 64K of data, do it something
  557. like this:
  558.  
  559.   type
  560.     PBuffer = ^TBuffer;
  561.     TBuffer = array[0..65521 div sizeof(integer)] of integer;
  562.  
  563.     PMatrix = ^TMatrix;
  564.     TMatrix = object(TBase)
  565.       rows,cols : word;
  566.       data : PBuffer;
  567.    
  568.       constructor init(arows,acols:word);
  569.       destructor done; virtual;
  570.   
  571.       function getval(i,j:word):integer;
  572.       procedure setval(i,j:word;value:integer);
  573.     end;
  574.  
  575.   constructor TMatrix.init;
  576.   begin
  577.     TBase.Init;
  578.     rows := arows;
  579.     cols := acols;
  580.     Getmem(data, rows*cols*sizeof(integer));
  581.   end;
  582.  
  583.   destructor TMatrix.done;
  584.   begin
  585.     Freemem(dat, rows*cols*sizeof(integer));
  586.     TBase.done;
  587.   end;
  588.  
  589.   function TMatrix.getval;
  590.   begin
  591.     getval := data^[cols*(i-1) + j];
  592.   end;
  593.  
  594.   procedure TMatrix.setval;
  595.   begin
  596.     data^[cols*(i-1) + j] := value;
  597.   end;
  598.  
  599. This untested code doesn't have the error checks that it should have, and
  600. doesn't run as fast as it could, but it's a start.  To use it, you just do
  601. something like this:
  602.  
  603.   var
  604.     m : PMatrix;
  605.     i,j : word;
  606.   begin
  607.     New(m, init(30,30));
  608.     for i:=1 to 30 do
  609.       for j:=1 to 30 do
  610.         m^.setval(i,j,random(8));
  611.   end.
  612.  
  613. The ugly example I posted before was trying to do some of the optimization;
  614. I wanted to be able to avoid the far call to SetVal or GetVal on every access.
  615.  I'm not that happy with the way I did it.
  616.  
  617.  
  618.  
  619.  
  620. --- Msg V3.2
  621.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  622.  * Tossed by SFToss v1.00b on 92/04/28  18:20:16
  623.  
  624. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  625.  
  626. Conference 4
  627. Date       04-27-92 09:01:24
  628. From       Dj Murdoch
  629. To         Keith Reid
  630. Subject    Re: FAT writing
  631.  
  632.  DM>Don't do this by editing the FAT.  Use Rename, or copy & delete.
  633.  
  634.  KR> Can't do it by Rename, dos will not accept a name with a path for the
  635.  KR> destination name.  
  636.  
  637. Try it.  The rename procedure does accept a path.  It's just COMMAND.COM's
  638. RENAME command that's crippled and won't accept one.
  639.  
  640.  
  641. --- Msg V3.2
  642.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  643.  * Tossed by SFToss v1.00b on 92/04/28  18:20:16
  644.  
  645. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  646.  
  647. Conference 4
  648. Date       04-27-92 09:07:11
  649. From       Dj Murdoch
  650. To         Trevor Carlsen
  651. Subject    Re: TP6 "bug"
  652.  
  653.   TC> It appears that TP6 does not calibrate the delay procedure 
  654.  TC> correctly when used with a fast machine - eg a 486/33.  I 
  655.  TC> would assume that Borland would be aware of this - are you?
  656.  
  657. Yes, though I thought the problem didn't crop up until you got a little bit
  658. faster than a 486/33.  It would certainly happen on a 486/50.  
  659.  
  660. I have the following patch, sent to me by Arno Haket.  I haven't applied it
  661. and I don't know exactly what it does; I wish it had been written using the
  662. DEBUG assemble command instead of the edit command.
  663.  
  664. ------------------------------------------------------
  665.  
  666. 4)  Delay() patch provided by Borland for 50 MHz 486s:
  667.  
  668. This is a patch for the CRT unit for Turbo Pascal version 6.0. It takes care
  669. of unpredictable DELAY times on computers faster than 30mhz.
  670.  
  671. To patch the CRT unit you need to have TURBO.TPL and TPUMOVER.EXE from Turbo
  672. Pascal 6.0, and DELAYPAT.BAT from this ZIP file all in the same directory.
  673. Also DOS's DEBUG must be in the current directory or in the current path.
  674.  
  675. MAKE THESE CHANGES TO A COPY OF TURBO.TPL NOT YOUR ORIGNAL!  DO NOT CHANGE
  676. YOUR ORIGNAL TURBO.TPL ONLY CHANGE YOUR WORKING COPY!
  677.  
  678. To install the new CRT unit Type: DELAYPAT
  679.  
  680. When the DOS prompt comes back the installation process is complete.  NOTE:
  681. the changes will only affect programs that are compiled after that patch has
  682. been made.
  683.  
  684. [ DELAYPAT.BAT: ]
  685.     Goto Batch
  686.     e 8BB 3E
  687.     e ADC 59 5B 5A 53 51 90
  688.     e AE5 14
  689.     e AF1 0E
  690.     e AF4 E8 04 00 4A 75 F6 CB BB 04 00 4B 75 FD 26 3A 05 E1 F5
  691.     w
  692.     q
  693.     :Batch
  694.     tpumover TURBO.TPL *CRT.TPU
  695.     debug CRT.TPU <Delaypat.BAT
  696.     tpumover TURBO.TPL +CRT.TPU
  697.     del crt.tpu
  698.  
  699.  
  700. --- Msg V3.2
  701.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  702.  * Tossed by SFToss v1.00b on 92/04/28  18:20:16
  703.  
  704. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  705.  
  706. Conference 4
  707. Date       04-28-92 00:41:22
  708. From       Trevor Carlsen
  709. To         All
  710. Subject    SBP+
  711.  
  712.  
  713.  
  714. Just reading through the ad for SBP+ again today and I noticed that they claim
  715. that P+ supports ALL memory models.  If that is true then the 64k limit for
  716. individual structures should not exist.  
  717.  
  718. Can anybody who uses the product confirm this?
  719.  
  720. TeeCee
  721.  
  722. --- TC-ED   v2.01  
  723.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  724.  * Tossed by SFToss v1.00b on 92/04/29  07:53:17
  725.  
  726. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  727.  
  728. Conference 4
  729. Date       04-28-92 01:41:47
  730. From       Trevor Carlsen
  731. To         John Giesbrecht
  732. Subject    TP6 "bug"
  733.  
  734.  
  735.  
  736.  TC> It appears that TP6 does not calibrate the delay procedure 
  737.  TC> correctly when used with a fast machine - eg a 486/33.
  738.  
  739.  JG> Do you know if the Delay() procedure in TPCRT/OPCRT (TurboPower) has 
  740.  
  741.  JG> the same problem?  (I own TPro but nothing like a 486/33 to test it 
  742.  JG> on.)
  743.  
  744. The same problem exists with TPro 5.07 and was fixed by 5.11.
  745. OPro 1.12 is Ok.  I no longer have the earlier versions of OPro set up on
  746. my disk.
  747.  
  748. TeeCee
  749.  
  750. --- TC-ED   v2.01  
  751.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  752.  * Tossed by SFToss v1.00b on 92/04/29  07:53:18
  753.  
  754. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  755.  
  756. Conference 4
  757. Date       04-28-92 08:49:57
  758. From       Trevor Carlsen
  759. To         Dj Murdoch
  760. Subject    Re: Help Needed with TP arrays
  761.  
  762.  
  763.  
  764.  TC> Actually by declaring the array as large as is possible 
  765.  TC> this cannot happen.  However my view on that method is 
  766.  TC> that it *might* allow a programmer to become complacent 
  767.  TC> about writing range checking routines. By forcing him to 
  768.  TC> turn off automatic range checking, I hope to increase the 
  769.  TC> awareness of the need for code to do it.  Either way the 
  770.  TC> method can be deadly if no RC code is written and there is 
  771.  TC> any possibility of out-of-range values.
  772.  
  773.  DM> That attitude seems to me to be exactly backwards.  Most programs have 
  774.  
  775.  DM> no range checking at all, because Borland defaults TP to $R-, and most 
  776.  
  777.  DM> people can't be bothered to do it manually.  If people did their 
  778.  DM> programming with $R+ always turned on, fewer bugs would make it out.  
  779.  
  780.  
  781. Backwards or not, it is my opinion!  (Perhaps that is a direct insight into
  782. my thought processes :-) )  Using your method will never produce a range-check
  783. error and it becomes easier for the method to over-write due to an oversight.
  784.  Using mine will *always* produce one if range checking is enabled and hopefully
  785. that in itself will force the programmer to realise the dangers and thus develop
  786. the necessary safety net. I am referring ONLY to code portions using dynamically
  787. allocated arrays.
  788.  
  789.  DM> If you develop programs with the $R- option set, you deserve all the 
  790.  
  791.  DM> trouble you can get when you miss doing one manual range check.
  792.  
  793. Generally speaking I agree and practice exactly that where possible.
  794.  
  795. TeeCee
  796.  
  797. --- TC-ED   v2.01  
  798.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  799.  * Tossed by SFToss v1.00b on 92/04/29  07:53:18
  800.  
  801. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  802.  
  803. Conference 4
  804. Date       04-28-92 19:47:00
  805. From       Terry Hughes
  806. To         Rob Kittredge
  807. Subject    Re: Looking for
  808.  
  809.  
  810. RK>Any plans on including SeaLink sometime in the future?  It
  811. RK>is a variation of Xmodem...I have been able to write one
  812. RK>myself but it is nowhere near as fancy as any of Async
  813. RK>Pro's protocols!!!  And probably not as reliable either!
  814.  
  815. Well, it is on the list of things-to-get-to but there are
  816. quite a few things in front of it.
  817.  
  818. -Terry
  819.  
  820.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  821.  
  822. --- Maximus 2.01wb
  823.  * Origin: The Programmers Playhouse (1:128/60)
  824.  * Tossed by SFToss v1.00b on 92/04/29  07:53:55
  825.  
  826. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  827.  
  828. Conference 4
  829. Date       04-28-92 00:00:02
  830. From       Terry Hughes
  831. To         John Giesbrecht
  832. Subject    TP6 "bug"
  833.  
  834.  
  835. JG>Trevor Carlsen (3:690/644) wrote to dj Murdoch on <26 Apr 07:49>:
  836.  
  837. JG> TC> It appears that TP6 does not calibrate the delay procedure
  838. JG> TC> correctly when used with a fast machine - eg a 486/33.
  839.  
  840. JG>Do you know if the Delay() procedure in TPCRT/OPCRT
  841. JG>(TurboPower) has the same problem?  (I own TPro but nothing
  842. JG>like a 486/33 to test it on.)
  843.  
  844. Very early versions of TPRO had a bug in the delay
  845. calibration but that's long been fixed. OPRO's delay
  846. calibration has always been correct on fast machines.
  847.  
  848. -Terry
  849.  
  850.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  851.  
  852. --- Maximus 2.01wb
  853.  * Origin: The Programmers Playhouse (1:128/60)
  854.  * Tossed by SFToss v1.00b on 92/04/29  07:53:55
  855.  
  856. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  857.  
  858. Conference 4
  859. Date       04-28-92 00:00:04
  860. From       Terry Hughes
  861. To         Trevor Carlsen
  862. Subject    TP6 "bug"
  863.  
  864.  
  865. TC>It appears that TP6 does not calibrate the delay procedure
  866. TC>correctly when used with a fast machine - eg a 486/33.  I
  867. TC>would assume that Borland would be aware of this - are you?
  868.  
  869. Strange. I know older versions of TP had such a problem but I
  870. thought the calibration technique they currently used worked on
  871. fast machines.
  872.  
  873. I just tested CRT's Delay on my 386/40 here at home and it
  874. worked. Plus, the internal variable DelayCnt (which holds the
  875. number of loops required to wait one millisecond) was only $4B0.
  876. Since this is a word, it should have quite a ways to go before
  877. wrapping -- meaning I'm surprised to see it wrap on a 486/33.
  878.  
  879. I assume OPCRT's Delay worked OK?
  880.  
  881. -Terry
  882.  
  883.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  884.  
  885. --- Maximus 2.01wb
  886.  * Origin: The Programmers Playhouse (1:128/60)
  887.  * Tossed by SFToss v1.00b on 92/04/29  07:53:56
  888.  
  889. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  890.  
  891. Conference 4
  892. Date       04-28-92 20:14:06
  893. From       Terry Hughes
  894. To         Joshua Kersey @ 930/22
  895. Subject    Re: FreePtr
  896.  
  897.  
  898. JK@9>-/----- Matt Heck said to All Who Would Be Guru -----\-
  899.  
  900. JK@9>MH> Can anyone tell me what the TP6.0 equivilant to the TP5.0 FreePtr
  901. JK@9>MH> is?
  902.  
  903. JK@9>HeapPtr
  904.  
  905. That's not correct. FreePtr and HeapPtr are quite different.
  906. See the various replies to Matt for an explanation of that
  907. difference.
  908.  
  909. -Terry
  910.  
  911.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  912.  
  913. --- Maximus 2.01wb
  914.  * Origin: The Programmers Playhouse (1:128/60)
  915.  * Tossed by SFToss v1.00b on 92/04/29  07:53:56
  916.  
  917. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  918.  
  919. Conference 4
  920. Date       04-28-92 00:00:08
  921. From       Terry Hughes
  922. To         John Gohde
  923. Subject    Re: Freeptr
  924.  
  925.  
  926. JG>*Can anyone tell me what the TP6.0 equivilant to the TP5.0 FreePtr is?
  927.  
  928. JG>Yeah, try:
  929.  
  930. JG>   Var FreePtr: Pointer;
  931.  
  932. JG>   FreePtr := Ptr(Seg(HeapEnd^)-$1000,0);
  933.  
  934. JG>And by the way, this solution is from a DOC included with TP6.0.
  935.  
  936. That would only work if the objective of the code
  937. referencing FreePtr was to return the top of memory. And
  938. even in those cases where it would return a reasonable
  939. result the entire purpose behind the calculation is moot.
  940. That is, you'd have a couple of calculations that
  941. essentially do nothing. And it doesn't address at all those
  942. cases where a program needs to set FreePtr or peek at the
  943. free list directly.
  944.  
  945. I couldn't find that suggestion in my TP6 docs so I assume
  946. it's something Borland added in later shipping releases of
  947. TP6. I hope it was accompanied by some warnings about its
  948. limitations.
  949.  
  950. -Terry
  951.  
  952.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  953.  
  954. --- Maximus 2.01wb
  955.  * Origin: The Programmers Playhouse (1:128/60)
  956.  * Tossed by SFToss v1.00b on 92/04/29  07:53:56
  957.  
  958. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  959.  
  960. Conference 4
  961. Date       04-28-92 09:09:55
  962. From       Dj Murdoch
  963. To         Matt Heck
  964. Subject    Re: FreePtr
  965.  
  966.   MH>      Rats. In what way does the heap manager differ from 5.0?
  967.  
  968. Instead of an array of records describing the holes in memory (the so called
  969. Free List in TP 4.0-5.5), TP 6.0 puts the records in the holes, and links
  970. them into a list.
  971.  
  972.  MH>      What I need to do is figure out how much memory to reserve for a TSR,
  973.  
  974.  MH>      like this:
  975.  
  976.  MH>      ResPara := Seg(FreePtr^)+$1000-PrefixSeg;     { 
  977.  MH> number of paragraphs }
  978.  
  979.  MH>      What would be the corresponding 6.0 method?
  980.  
  981.           ResPara := Seg(HeapEnd) - PrefixSeg;
  982.  
  983. should work, but I haven't tested it.
  984.  
  985. it is we are), who had a primitive savage belief in...
  986.  
  987.  CP>some things in this world that cannot be explained, and
  988.   some things that wil CP>never be explained by our scientists, IMHO.
  989.  
  990.   Quite true.  Doesn't mean God did it.
  991.  
  992.  
  993. CP>I'm positive most of them would most likely be killed or seriously hurt, but
  994.  
  995. CP>some would live I would think.
  996.  
  997. CP>But you're talking about 3 million couples. That just makes that one inciden
  998. CP>Alan brought up sound even better. That ONE incident was a miracle. I'm sure
  999.  
  1000.  
  1001.   You don't understand statistics.  Let me explain.  Think of it this
  1002.   way:  If I make a million sided dice, and it comes up on a million,
  1003.   1000 times on 1000000 throws, you probably would call that chance, and
  1004.   not a miracle.  However, if the number 1,000,000 has some special
  1005.   significance (as does people surviving bad accidents) and I throw the
  1006.   dice once and it comes up on a million, does that make it a miracle?
  1007.   Hardly.  Just one of a million different possibilities, and in the
  1008.   case of the car accident, it's the same thing, although there are a
  1009.   different number of possible outcomes (possibly more?  The car flips
  1010.   on its front, it's back, it's back by 90 degrees, by 89.999 degrees,
  1011.   etc)
  1012.  
  1013.   CP>the family members of those that survived that ordeal would
  1014.   agree with that.
  1015.  
  1016.   If I get a bunch of Zulu warriors and ask them if they agree on their
  1017.   religious beliefs, does that make them right in your eyes?  In some
  1018.   things, opinion polls mean didly.  If I get all of those people to
  1019.   somehow think that I saved their families by farting at the exact same
  1020.   time as the accident (which is entirely possibly if I've been eating
  1021.   something noxious), it proves nothing, save for their gullibility.
  1022.  * SLMR 2.0 * Early one June morning in 1872 I murdered my father --
  1023. --- SuperQWK 1.16 Beta-5 (Reg)
  1024.  * Origin: Starship Enterprise - SuperBBS Support/Registration (1:221/187)
  1025.  * Tossed by SFToss v1.00b on 92/04/29  15:57:11
  1026.  
  1027. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1028.  
  1029. Conference 4
  1030. Date       04-28-92 09:16:33
  1031. From       Dj Murdoch
  1032. To         J J Marquez
  1033. Subject    Re: Turbo 5.5 doesn't re
  1034.  
  1035.   JJ>    I am still not convinced of it's "smarts" in this 
  1036.  JJ> matter. If I use the TEST8087 dealie in a CASE statement, 
  1037.  JJ> does that not constitute "needing to use it" in order to 
  1038.  JJ> use the TEST8087 variable (well, CONSTANT, actually...) 
  1039.  JJ> with any success ??
  1040.  
  1041. Here are two justifications:
  1042.  
  1043. 1.  The lawyer's justification:
  1044.  
  1045. The TEST8087 variable is performing exactly as documented.  It isn't supposed
  1046. to tell you what sort of coprocessor you've got, it's supposed to tell you
  1047. the result of the detection logic.  If you don't have the $N+ option set,
  1048. the logic doesn't see a thing.
  1049.  
  1050. 2.  The mechanic's justification:
  1051.  
  1052. The TEST8087 variable isn't data used by the floating point code, it's a part
  1053. of the regular system variables.  Looking at it doesn't pull in the detection
  1054. code any more than looking at any of the Ovr* variables forces your program
  1055. to be overlaid.
  1056.  
  1057. --- Msg V3.2
  1058.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1059.  * Tossed by SFToss v1.00b on 92/04/30  07:10:20
  1060.  
  1061. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1062.  
  1063. Conference 4
  1064. Date       04-28-92 09:57:41
  1065. From       Dj Murdoch
  1066. To         Dj Murdoch
  1067. Subject    Re: Turbo 5.5 doesn't re
  1068.  
  1069.   DM> 1.  The lawyer's justification:
  1070.  
  1071.  DM> The TEST8087 variable is performing exactly as documented. 
  1072.  DM>  It isn't supposed to tell you what sort of coprocessor 
  1073.  DM> you've got, it's supposed to tell you the result of the 
  1074.  DM> detection logic.  If you don't have the $N+ option set, 
  1075.  DM> the logic doesn't see a thing.
  1076.  
  1077. Ooops, I mean if you have $N+ set, but don't use anything that needs the floatin
  1078.  point code, the logic doesn't see a thing.
  1079.  
  1080. --- Msg V3.2
  1081.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1082.  * Tossed by SFToss v1.00b on 92/04/30  07:10:20
  1083.  
  1084. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1085.  
  1086. Conference 4
  1087. Date       04-29-92 20:34:00
  1088. From       Norbert Igl
  1089. To         Daniel Schlenzig
  1090. Subject    Soundblaster
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  >> I think that was the right port... if that doesn't work, maybe it was
  1097.  >> 544, 540, or 550.
  1098.  > The Soundblaster DSP accessing port is 2xCh, where x is the setting
  1099.  > of the jumper (2, 3, 4).
  1100.  
  1101.    544     <=>   220         !!!
  1102.       (10)          (16)
  1103.  
  1104. Bye from Germany, Norbert
  1105.  
  1106. ---
  1107.  * Origin: Let's talk about hex, baby.... (2:241/5300.3)
  1108.  * Tossed by SFToss v1.00b on 92/04/30  07:10:32
  1109.  
  1110. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1111.  
  1112. Conference 4
  1113. Date       04-30-92 01:15:01
  1114. From       Trevor Carlsen
  1115. To         Terry Hughes
  1116. Subject    TP6 "bug"
  1117.  
  1118.  
  1119.  
  1120.  TC>It appears that TP6 does not calibrate the delay procedure
  1121.  TC>correctly when used with a fast machine - eg a 486/33.  I
  1122.  TC>would assume that Borland would be aware of this - are you?
  1123.  
  1124.  TH> Strange. I know older versions of TP had such a problem but I
  1125.  TH> thought the calibration technique they currently used worked on
  1126.  TH> fast machines...
  1127.  TH> ... I assume OPCRT's Delay worked OK?
  1128.  
  1129. Sure did!  So did TPro's (version 5.11) but just for curiosity I also tested
  1130. TPro 5.07 and it was incorrect.
  1131.  
  1132. TeeCee
  1133.  
  1134. --- TC-ED   v2.01  
  1135.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1136.  * Tossed by SFToss v1.00b on 92/04/30  20:36:21
  1137.  
  1138. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1139.  
  1140. Conference 4
  1141. Date       04-30-92 01:21:53
  1142. From       Trevor Carlsen
  1143. To         Shelby Crane
  1144. Subject    Re: $80?
  1145.  
  1146.  
  1147.  
  1148.  SC> How did you figure the haxadecimal number? I know that the
  1149.  SC> $60 is the keyboard but I'm not sure why it is comparing it
  1150.  SC> to the $80 which I have no idea what is.
  1151.  
  1152. Port[$60] contains details of the last keypress/keyrelease.  If the msb is
  1153. set it indicates a release rather than a press.  Therefore any value of $80
  1154. or higher indicates a key release.
  1155.  
  1156. TeeCee
  1157.  
  1158. --- TC-ED   v2.01  
  1159.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1160.  * Tossed by SFToss v1.00b on 92/04/30  20:36:21
  1161.  
  1162. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1163.  
  1164. Conference 4
  1165. Date       04-30-92 01:28:18
  1166. From       Trevor Carlsen
  1167. To         J J Marquez
  1168. Subject    Re: dectecing coprocessor
  1169.  
  1170.  
  1171.  
  1172.  JM> ... Inclusion and use of the TEST8087 item in a user program
  1173.  JM> ought to work, even if you do nothing else...
  1174.  
  1175. If that means linking in what is really unnecessary code then I disagree with
  1176. you.  I prefer the smart linking.
  1177.  
  1178.  JM> ... Or, AT LEAST have the docs clearly tell you that it
  1179.  JM> won't work without the other code present.
  1180.  
  1181. To my way of thinking that is the correct way to do it.
  1182.  
  1183. TeeCee
  1184.  
  1185. --- TC-ED   v2.01  
  1186.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1187.  * Tossed by SFToss v1.00b on 92/04/30  20:36:21
  1188.  
  1189. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1190.  
  1191. Conference 4
  1192. Date       04-30-92 01:45:11
  1193. From       Trevor Carlsen
  1194. To         Jud Mccranie
  1195. Subject    Re: Features Lacking In Tp
  1196.  
  1197.  
  1198.  
  1199.  TC> mickey-mouse language.  If you do not like something you should
  1200.  TC> not buy it.
  1201.  
  1202.  JM> Many times we can't get a look at something first...
  1203.  
  1204. If the product is not too new it is usually easy enough to find reviews or
  1205. somebody that can demonstrate it.  If - as in the case of SBP+ - it is advance
  1206. advertising of a product yet to be released and inviting orders then the best
  1207. way to go is write a letter requesting details of points not made clear or
  1208. omitted in the ads.  
  1209.  
  1210. In Australia, and I think the same applies in the US, there is consumer legislat
  1211. on that allows you to return the product for refund if it does not stand up
  1212. to claims or is unsuitable for the use it is intended for.
  1213.  
  1214. TeeCee
  1215.  
  1216. --- TC-ED   v2.01  
  1217.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1218.  * Tossed by SFToss v1.00b on 92/04/30  20:36:21
  1219.  
  1220. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1221.  
  1222. Conference 4
  1223. Date       04-30-92 02:23:09
  1224. From       Trevor Carlsen
  1225. To         Rob Kittredge
  1226. Subject    Borland, OS/2 2.0, and you
  1227.  
  1228.  
  1229.  
  1230.  RK> I have purchased a copy of Borland C++ 3.0 and it *IS* a nice compiler 
  1231.  
  1232.  RK> but currently all of my programs are written in Turbo Pascal and it 
  1233.  RK> would take me years to convert them to C++ so I could run under OS/2.  
  1234.  
  1235.  
  1236.  RK> Well, thanks for your message it's interesting to hear what other 
  1237.  RK> people are thinking about this tragedy :-)
  1238.  
  1239. I wish I was as sure of winning Lotto as I am that an OS/2 version of TP (or
  1240. a TP compatible) will not be far away. I think it just a matter of being patient
  1241.  
  1242.  
  1243. TeeCee
  1244.  
  1245. --- TC-ED   v2.01  
  1246.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1247.  * Tossed by SFToss v1.00b on 92/04/30  20:36:21
  1248.  
  1249. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1250.  
  1251. Conference 4
  1252. Date       04-30-92 02:37:51
  1253. From       Trevor Carlsen
  1254. To         Chris Kelling
  1255. Subject    Re: Help Needed with TP arrays
  1256.  
  1257.  
  1258.  
  1259.  TC> you obviously disagree, why not prove your point of view?  :-) 
  1260.  
  1261.  CK> Why do you say that is not true dynamic varibales.  The burden of 
  1262.  CK> proff is on you...
  1263.  
  1264. Yeah I guess it is :-)
  1265.  
  1266. By definition something that is dynamic is subject to change.  In the subject
  1267. at hand I take that to mean that an array can be dimensioned dynamically at
  1268. run-time.  This is not possible in TP.  The following will not compile -
  1269.  
  1270.   var
  1271.     Thearray : array[0..max] of byte;
  1272.  
  1273. *if* max is not a constant.  However as has been demonstrated there are ways
  1274. around this restriction.  All involve dynamically allocating only as much
  1275. memory as is needed for the "dynamic array" on the heap.  Methods differ slightl
  1276.  on how to go about this, but one thing is constant - the programmer MUST
  1277. write bound checking code or face disaster, as TP's range checking is of no
  1278. use here.
  1279.     
  1280. TeeCee
  1281.  
  1282.  
  1283. --- TC-ED   v2.01  
  1284.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1285.  * Tossed by SFToss v1.00b on 92/04/30  20:36:21
  1286.  
  1287. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1288.  
  1289. Conference 4
  1290. Date       04-30-92 19:54:15
  1291. From       Trevor Carlsen
  1292. To         Jud Mccranie
  1293. Subject    Re: Features Lacking In Tp
  1294.  
  1295.  
  1296.  
  1297.  DM> I don't see any need for static data greater than 64K, but I'd
  1298.  
  1299.  JM> Well, it is much easier and faster if you have data
  1300.  JM> available in memory, and if you have more than 64K of it,
  1301.  JM> you need more than 64K.
  1302.  
  1303. Data on the heap is just as much in  memory as any other.  It is slower to
  1304. access, but no user would ever detect that as microseconds only are involved.
  1305.  I consider that it is desirable to have individual structures that can exceed
  1306. a segment but I still see no justification for global data space exceeding
  1307. that.  Your comment that it is MUCH easier and faster just doesn't hold up.
  1308.  
  1309. Here are some interesting results of writing data to a 60K structure on the
  1310. heap and also statically.  Each element is written individually 100 times
  1311. so that is 6.144 million data writes - something that just doesn't happen
  1312. in real life applications.
  1313.  
  1314.   To static  memory - 2.6095 seconds
  1315.   To dynamic memory - 3.9142 seconds
  1316.  
  1317. or a difference of 1/5th of a microsecond (213 nanoseconds) per element!
  1318.  
  1319. Even though that is on a fast machine, even on a 4.77mHz PC it is still hardly
  1320. what I would call worth worrying about.  However in a big structure which
  1321. can easily require operations of the order of 100s of thousands read/writes
  1322. in a sort or similar, the overhead involved because of the segment limitation
  1323. on single structures becomes highly significant.
  1324.  
  1325. TeeCee
  1326.  
  1327. --- TC-ED   v2.01  
  1328.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1329.  * Tossed by SFToss v1.00b on 92/04/30  20:36:22
  1330.  
  1331. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1332.  
  1333. Conference 4
  1334. Date       04-30-92 20:02:25
  1335. From       Trevor Carlsen
  1336. To         Damian Slee
  1337. Subject    Saving Screens
  1338.  
  1339.  
  1340.  
  1341.  TC> may cause a "snow" effect.  This can be countered by only
  1342.  TC> doing accesses between vertical retraces.  As such cards are
  1343.  TC> relatively rare now, most do not bother.
  1344.  
  1345.  DS>   What does this mean, any how do I implement it?
  1346.  
  1347. Any direct access of video RAM during a vertical retrace scan causes a "snow"
  1348. effect.  To avoid this the access should examine the video controller's register
  1349.  to determine when it is safe to do the write.  On a 4.77mHz PC about 900
  1350. characters can be written in the "safe" time.  Any attempt to disable the
  1351. scan for more than one scan will result in noticeable flicker.
  1352.  
  1353. A good book to read if you need more information is Richard Wilton's "Programmer
  1354. s Guide to PC and PS/2 Video Systems"
  1355.  
  1356. EGA and VGA cards, along with most CGA cards do not have the problem as their
  1357. circuitry is already designed to prevent the problem.
  1358.  
  1359. TeeCee
  1360.  
  1361. --- TC-ED   v2.01  
  1362.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1363.  * Tossed by SFToss v1.00b on 92/04/30  20:36:22
  1364.  
  1365. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1366.  
  1367. Conference 4
  1368. Date       04-29-92 09:09:30
  1369. From       Dj Murdoch
  1370. To         Richard Morris
  1371. Subject    Re: Turbovision - Off Topic?
  1372.  
  1373.   RM> Spell checking, know any good flat dictionaries?
  1374.  
  1375. Not a flat one, but I have code to read the PC Write dictionary of a few version
  1376.  ago.  
  1377.  
  1378.  
  1379. --- Msg V3.2
  1380.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1381.  * Tossed by SFToss v1.00b on 92/05/01  06:17:11
  1382.  
  1383. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1384.  
  1385. Conference 4
  1386. Date       04-29-92 18:25:00
  1387. From       Dj Murdoch
  1388. To         daniel prosser
  1389. Subject    Re: Chaining interrupts
  1390.  
  1391.   > Does anyone have a procedure or asembly source that will allow
  1392.  > chaining
  1393.  > of interrupts in pascal WITHOUT using SetIntVec, since that calls INT
  1394.  > 21h and therefore making it impossible to Chain INT 21h. Any help
  1395.  > would
  1396.  > be appreciated!
  1397.  
  1398.  DP> You can take over INT 21h with the standard int 21h function 35h...
  1399.  DP> and I think it is also possible to change it with SetIntVect
  1400.  
  1401. One thing to watch out for if you take over INT 21:  you can't use the regular
  1402. TP interrupt routine exit code.  It ends with an IRET; that'll wipe out the
  1403. flags being returned by INT 21.  You need to rewrite it to return with a RETF 2.
  1404.  
  1405.  
  1406. --- Msg V3.2
  1407.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1408.  * Tossed by SFToss v1.00b on 92/05/01  06:17:11
  1409.  
  1410. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1411.  
  1412. Conference 4
  1413. Date       05-01-92 03:53:34
  1414. From       Trevor Carlsen
  1415. To         Benjamin Schollnick
  1416. Subject    Re: Procedures...
  1417.  
  1418.  
  1419.  
  1420.  BS>     And I've found some strange stuff in the code I'm rewriting...
  1421.  BS>     Who agrees with this practice?
  1422.  BS>         Repeat
  1423.  BS>         Until True = False;
  1424.  BS>     That's _crazy_....The loop never be halted except by a HALT, or
  1425.  BS>     MAYBE a exit....And that's totally against everything I've learned
  1426.  BS>     and taught!
  1427.  
  1428. That is a perfectly valid technique.  I use it frequently in input loops where
  1429. it can make the code cleaner and more readable.  Usually I add a comment like -
  1430.  
  1431.  { halt occurs in procedure ProcessInput if escape key pressed }
  1432.  
  1433. Sometimes the halt might occur in several different places.  There are all
  1434. sorts of reasons and most are perfectly valid.
  1435.  
  1436. BTW... Please clean up your quoting.  Do not quote the kludge lines.
  1437.  
  1438. TeeCee
  1439.  
  1440. --- TC-ED   v2.01  
  1441.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1442.  * Tossed by SFToss v1.00b on 92/05/01  21:05:54
  1443.  
  1444. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1445.  
  1446. Conference 4
  1447. Date       05-01-92 04:03:57
  1448. From       Trevor Carlsen
  1449. To         Roger Joelsson
  1450. Subject    Sources for Mailer
  1451.  
  1452.  
  1453.  
  1454.  BS> BT is written in C, but translating to Pascal isn't too
  1455.  BS> dificult, it just takes a *long* time...
  1456.  
  1457.  RJ> Well, it isn't *too* easy, but I'm sure that the code would be less 
  1458.  RJ> efficient written i Turbo Pascal, rather than compiled with MS C 
  1459.  RJ> 6/7.0?
  1460.  RJ> Anyone who disagrees in this matter? :-)
  1461.  
  1462. Yes...me! :-)
  1463.  
  1464. It seems a common belief that C programs, especially those compiled with an
  1465. optimising compiler such as MS C, are inherently more efficient and/or faster
  1466. than Turbo Pascal programs.
  1467.  
  1468. This is not necessarily so.
  1469.  
  1470. Most TP programs will be smaller in .exe size than C programs.  Many will
  1471. also be faster although this is dependant on the type of operation being perform
  1472. d. You certainly cannot make blanket statements such as you have done above
  1473. and be accurate. Sometimes such statements will be true and sometimes false.
  1474.  
  1475. TeeCee
  1476.  
  1477. --- TC-ED   v2.01  
  1478.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1479.  * Tossed by SFToss v1.00b on 92/05/01  21:05:54
  1480.  
  1481. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1482.  
  1483. Conference 4
  1484. Date       05-01-92 04:13:40
  1485. From       Trevor Carlsen
  1486. To         Keith Dombrowski
  1487. Subject    Re: EMS w/Overlays
  1488.  
  1489.  
  1490.  
  1491.  DM> It's probably because you're not executing the exit
  1492.  DM> procedure properly.  That can happen if you quit partway
  1493.  DM> through the program in the IDE, or if you install a new exit
  1494.  DM> procedure that doesn't call the old one.
  1495.  
  1496.  KD>    Well, actualy it never happens in the IDE, but the second one may 
  1497.  
  1498.  KD> be the ticket, the door library I am using has it's own exit procedure 
  1499.  
  1500.  KD> and as I don;t have the source, I can't tell if it is executing the 
  1501.  KD> default one. Thanks for the info, I'll have to send the author a 
  1502.  KD> netmail about it.
  1503.  
  1504. Hard-fast-rule-number-1.
  1505.  
  1506. NEVER use units written by third parties if you do not have the source!
  1507.  
  1508. However that is not going to solve your problem here by being wise after the
  1509. event. :-)   So make your own little exit procedure and place it in its own
  1510. unit.  Make that unit the *first* unit in your uses declarations.  If it is
  1511. not being executed then the other unit is not chaining back properly.
  1512.  
  1513. TeeCee
  1514.  
  1515. --- TC-ED   v2.01  
  1516.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1517.  * Tossed by SFToss v1.00b on 92/05/01  21:05:54
  1518.  
  1519. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1520.  
  1521. Conference 4
  1522. Date       05-01-92 04:20:14
  1523. From       Trevor Carlsen
  1524. To         Humberto Garza
  1525. Subject    Joystick
  1526.  
  1527.  
  1528.  
  1529.  HG>  Function BitOn(Position, TestByte : Byte) : Boolean;
  1530.  HG>  (* Individual Bit Testing function *)
  1531.  HG>    Var
  1532.  HG>      bt : byte;
  1533.  HG>    Begin
  1534.  HG>    bt := $01;
  1535.  HG>    bt := bt Shl Position;
  1536.  HG>    BitOn := (bt And TestByte) > 0;
  1537.  HG>    End;
  1538.  
  1539. Better here would be -
  1540.   function BitOn(Position, TestByte):boolean;
  1541.     begin
  1542.       BitOn := odd(TestByte shr Position);
  1543.     end;
  1544.  
  1545. BTW ... Hi-bit characters are not permitted in this echo.  Please amend your
  1546. quoting style appropriately.  There is also a hi-bit character in your reader's
  1547. brag line.
  1548.  
  1549. TeeCee
  1550.  
  1551. --- TC-ED   v2.01  
  1552.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1553.  * Tossed by SFToss v1.00b on 92/05/01  21:05:54
  1554.  
  1555. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1556.  
  1557. Conference 4
  1558. Date       05-01-92 05:08:45
  1559. From       Trevor Carlsen
  1560. To         Stevo Wierengo
  1561. Subject    BBS Lockup 2/6
  1562.  
  1563.  
  1564.  
  1565. Steve,  I can't solve your lock-up problems but perhaps the following suggestion
  1566. might help -
  1567.  
  1568.  SW>     ban := UpCase(readportkey);
  1569.  
  1570. Why change the charcater to upper case when later in the program you exert
  1571. a great deal of effort to change it to lower case?
  1572.  
  1573.  SW>                   If ban = 'A' then ban := 'a' else if ban = 'B' then 
  1574.  
  1575.  SW> ban
  1576.  SW>                   Else if ban = 'C' then ban := 'c' else if ban = 'D'
  1577.  SW>                   Else if ban = 'E' then ban := 'e' else if ban = 'F'
  1578.  SW>                   Else if ban = 'G' then ban := 'g' else if ban = 'H'
  1579.  
  1580. etc...
  1581.  
  1582. However if it is essential that you change to upper case and then back all
  1583. of these lines could be replaced by
  1584.   
  1585.   ban := LowCase(ban);  
  1586.  
  1587. with the relevant function being;
  1588.   function LowCase(var ch): char;
  1589.     begin
  1590.       case char(ch) of
  1591.        'A'..'Z': LowCase := chr(byte(ch) and $df);
  1592.       end;
  1593.     end;
  1594.  
  1595. TeeCee
  1596.  
  1597. --- TC-ED   v2.01  
  1598.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1599.  * Tossed by SFToss v1.00b on 92/05/01  21:05:54
  1600.  
  1601. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1602.  
  1603. Conference 4
  1604. Date       05-01-92 05:26:52
  1605. From       Trevor Carlsen
  1606. To         Stevo Wierengo
  1607. Subject    BBS Lockup 6/6
  1608.  
  1609.  
  1610.  
  1611.  SW> PROCEDURE FormatUD;   
  1612.  SW> Begin
  1613.  SW>   FillChar(ud.user, (SizeOf(ud.user)-Length(ud.user)),' ');
  1614.  SW>   FillChar(ud.pw, (SizeOf(ud.pw)-Length(ud.pw)),' ');
  1615.  SW>   FillChar(ud.ph1, (SizeOf(ud.ph1)-Length(ud.ph1)),' ');
  1616.  SW>   FillChar(ud.ph2, (SizeOf(ud.ph2)-Length(ud.ph2)),' ');
  1617.  SW>   FillChar(ud.add1, (SizeOf(ud.add1)-Length(ud.add1)),' ');
  1618.  SW>   FillChar(ud.city, (SizeOf(ud.city)-Length(ud.city)),' ');
  1619.  SW>   FillChar(ud.state, (SizeOf(ud.state)-Length(ud.state)),' ');
  1620.  SW>   FillChar(ud.zip, (SizeOf(ud.zip)-Length(ud.zip)),' ');
  1621.  SW>   FillChar(ud.born, (SizeOf(ud.born)-Length(ud.born)),' ');
  1622.  SW>   FillChar(ud.ansi, (SizeOf(ud.ansi)-Length(ud.ansi)),' ');
  1623.  SW>   FillChar(ud.bank, (SizeOf(ud.bank)-Length(ud.bank)),' ');
  1624.  SW>   FillChar(ud.dls, (SizeOf(ud.dls)-Length(ud.dls)),' ');
  1625.  SW>   FillChar(ud.uls, (SizeOf(ud.uls)-Length(ud.uls)),' ');
  1626.  SW>   FillChar(ud.times, (SizeOf(ud.times)-Length(ud.times)),' ');
  1627.  SW>   FillChar(ud.level, (SizeOf(ud.level)-Length(ud.level)),' ');
  1628.  SW> End;
  1629.  
  1630. This monstrosity could be eliminated by a simple:
  1631.   procedure FormatUD;
  1632.     begin
  1633.       FillChar(ud,sizeof(ud),0);
  1634.     end;
  1635. placed at the start of your procedure.
  1636.       
  1637.  
  1638.  
  1639. --- TC-ED   v2.01  
  1640.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1641.  * Tossed by SFToss v1.00b on 92/05/01  21:05:54
  1642.  
  1643. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1644.  
  1645. Conference 4
  1646. Date       05-01-92 15:49:50
  1647. From       Trevor Carlsen
  1648. To         Benjamin Schollnick
  1649. Subject    Re: Procedures...
  1650.  
  1651.  
  1652.  
  1653.  TC>   JS> If ParamCount <> 3 then begin
  1654.  TC>   JS>   ClrScr ;
  1655.  TC>   JS>   WriteLN('To use this program you MUST have 3 arguments to 
  1656.  TC>   JS>   WriteLN('Program what you want it to do!') ;
  1657.  TC>   JS>   WriteLN('Test -A -B -C') ;
  1658.  TC>   JS>   Exit ;           { Wrong Parameter count! Abort! }
  1659.  TC>   JS> end ;
  1660.  TC>   JS> ...
  1661.  TC>   JS> ...  { Program Code here. }
  1662.  TC>   JS> ...
  1663.  TC>   JS> End.
  1664.  
  1665.  BS>     Would cause a bomb instead of exiting the "Main" code...Because it
  1666.  BS>     would return to the main block, and "not trap the error"....Halt
  1667.  BS>     would of been the correct use as I showed in my reply...
  1668.  
  1669. Whilst I agree with your suggestion that the use of halt instead of the exit
  1670. is preferable, the above statement of yours is incorrect.  In the above case
  1671. the exit
  1672.  
  1673. "Exits immediately from the current block.
  1674.  
  1675. Syntax:
  1676.   Exit;
  1677.  
  1678. If the current block is the main program, Exit
  1679. causes the program to terminate."  (from help file).
  1680.  
  1681. TeeCee
  1682.  
  1683.  
  1684.  
  1685. --- TC-ED   v2.01  
  1686.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1687.  * Tossed by SFToss v1.00b on 92/05/01  21:05:54
  1688.  
  1689. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1690.  
  1691. Conference 4
  1692. Date       05-01-92 22:21:00
  1693. From       Werner Berghofer
  1694. To         Roger Joelsson
  1695. Subject    SAA/CUA standards
  1696.  
  1697.  
  1698.  
  1699.  
  1700.  
  1701.        Hi, Roger.
  1702.  
  1703.  > Do you know where to get some of these books?
  1704.  > Are they "publicly" available from IBM?
  1705.  
  1706.        Yes, they are -- at least here in the country where I live.  Contact
  1707. any IBM authorized dealer, I think he should be able to order these books
  1708. from IBM for you.  Probably you also will be able to order the books in a
  1709. book store spezialized in EDP related topics.
  1710.  
  1711.  > That DOS Shell program that comes with MS-DOS 4.01 and 5.0,
  1712.  > isn't it a typical example on implenting SAA/CUA?
  1713.  
  1714.        The DOS 5.0 shell is more typical for SAA/CUA than the 4.x shell was;
  1715. another good example for this kind of user interface is DOS 5.0's QBASIC.EXE
  1716. (aka EDIT.COM) and OS/2 1.3 Presentation Manager (didn't have a chance to
  1717. look at OS/2 2.0 PM yet, sorry).
  1718.  
  1719.  > (greetings from Sweden!)
  1720.  
  1721.        The same to you from Vienna, Austria.
  1722.  
  1723.        Werner.
  1724.  
  1725. ---
  1726.  * Origin: Real programmers use COPY CON PROGRAM.EXE (2:310/90.100)
  1727.  * Tossed by SFToss v1.00b on 92/05/02  15:11:29
  1728.  
  1729. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1730.  
  1731. Conference 4
  1732. Date       05-01-92 23:06:51
  1733. From       Trevor Carlsen
  1734. To         All
  1735. Subject    16550 chip
  1736.  
  1737.  
  1738.  
  1739. Does anybody have any Pascal (or assembler) code that will demonstrate a fool-pr
  1740. of way of determining if the UART is a 16550, 16450 or 8250?
  1741.  
  1742. TeeCee
  1743.  
  1744. --- TC-ED   v2.01  
  1745.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1746.  * Tossed by SFToss v1.00b on 92/05/02  15:11:52
  1747.  
  1748. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1749.  
  1750. Conference 4
  1751. Date       05-02-92 12:35:46
  1752. From       Trevor Carlsen
  1753. To         Matt Heck
  1754. Subject    Borland, OS/2 2.0, and you
  1755.  
  1756.  
  1757.  
  1758.  MH> Is there any point to a 286 with 640k and a 40MB HDD running OS/2?
  1759.  
  1760. None at all, mainly because it will not run on a 286.  OS/2 2.0 is a 32 bit
  1761. system specifically coded for 386/486 operation.
  1762.  
  1763.  MH>      And either way, are the rest of you planning to program for it, 
  1764.  
  1765.  MH> thereby attempting to force us to shell out more cash?
  1766.  
  1767. I'll wait and see.  However when TP is released for OS/2 then I will definitely
  1768. buy it for a look.  If the demand is there, then there is no decision required.
  1769.  
  1770. TeeCee
  1771.  
  1772. --- TC-ED   v2.01  
  1773.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1774.  * Tossed by SFToss v1.00b on 92/05/02  15:11:52
  1775.  
  1776. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1777.  
  1778. Conference 4
  1779. Date       05-02-92 12:45:29
  1780. From       Trevor Carlsen
  1781. To         John Gohde
  1782. Subject    A Virtuous Pascal ...
  1783.  
  1784.  
  1785.  
  1786.  JG> POINT ONE: TP4 has more than enough features to keep a first time
  1787.  JG> non-genius casual programmer busy for one year of devoted study.
  1788.  
  1789. Agree 100%.  Well put.
  1790.  
  1791.  JG> POINT TWO: There  is a market for a simple  and stable real world
  1792.  JG> version  of   Pascal...
  1793.  
  1794. Agree 100% - again!
  1795.  
  1796.  JG> POINT THREE: Why pay for features and learn features that will be
  1797.  JG> out of  date by the  time you  get  around to using  them for the
  1798.  JG> first time?
  1799.  JG> In other words, why pay for TV version 6 if you wont use TV until
  1800.  JG> version 7 or 8 exists?
  1801.  
  1802. Three in a row!
  1803.  
  1804.  JG> POINT FOUR: There is a market segment who would buy TP4 at USA$40
  1805.  JG> rather than  TP6 at USA$110, if  they had that option.  And, this
  1806.  JG> alleged  FACT  has  nothing  whatsoever  to  do  with  Borland TP
  1807.  JG> propaganda.
  1808.  
  1809. You been reading my mind?
  1810.  
  1811.  JG> POINT FIVE: The availability of a good, simple, and stable Pascal
  1812.  JG> at  USA$40 would  ONLY tend  to promote  the use  of PASCAL  as a
  1813.  JG> programming language; whereas the  current marketing practises of
  1814.  JG> Borland  MAY not  have the  promotion of  Pascal as a programming
  1815.  JG> language as a priority.
  1816.  
  1817. I hate to say this - but that's five.
  1818.  
  1819. You have just determined that there is a niche market that would almost certainl
  1820.  be quite lucrative... Go for it.
  1821.  
  1822. (See?  when you stick to facts and objectivity you and I CAN agree :-)  )
  1823.  
  1824. TeeCee
  1825.  
  1826. --- TC-ED   v2.01  
  1827.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1828.  * Tossed by SFToss v1.00b on 92/05/02  15:11:52
  1829.  
  1830. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1831.  
  1832. Conference 4
  1833. Date       05-02-92 17:21:47
  1834. From       Trevor Carlsen
  1835. To         Lee Cassar
  1836. Subject    Need some help
  1837.  
  1838.  
  1839.  
  1840.  LC> I need some help.  I want to know how to turn on and off the locks on 
  1841.  
  1842.  LC> the keyboard(scroll, num, and caps) using a turbo pascal routine.
  1843.  LC> Does anyone have any ideas?
  1844.  LC> (I have turbo Pascal 6.0 Professional)
  1845.  
  1846. type
  1847.   shiftstatus = set of (RightShift, LeftShift, Ctrl, Alt,
  1848.                         ScrollLock, NumLock, CapsLock, InsertOn);
  1849. var
  1850.   KbdStatus   : shiftstatus absolute $40:$17;
  1851.  
  1852. Eg.  To turn caps lock on -
  1853.  
  1854. KbdStatus := KbdStatus + [CapsLock];
  1855.  
  1856.      To turn it off -
  1857.  
  1858. KbdStatus := KbdStatus - [CapsLock];
  1859.  
  1860. TeeCee
  1861.  
  1862.  
  1863.  
  1864. --- TC-ED   v2.01  
  1865.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1866.  * Tossed by SFToss v1.00b on 92/05/02  15:11:52
  1867.  
  1868. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1869.  
  1870. Conference 4
  1871. Date       05-02-92 17:32:39
  1872. From       Trevor Carlsen
  1873. To         Greg Belanger
  1874. Subject    Encryption of sorts..
  1875.  
  1876.  
  1877.  
  1878.  GB> I'm lookin for a way to Encrypt various aspects of my programs.  For 
  1879.  
  1880.  GB> example, I know it's quite easy to use a HEX editor and go in and edit 
  1881.  
  1882.  GB> the program name, autor and copyright info.  Is there a way to make 
  1883.  GB> this "text" unmodifiable?  I'm looking for a nice, simple routine..not 
  1884.  
  1885.  GB> 400 lines of encryption code.  Any suggestions?
  1886.  
  1887. By far the easiest and safest way of doing what you want is to place all textual
  1888. information used by your program in a file and encrypt that file.  Unencrypt
  1889. it during the initialisation routine.
  1890.  
  1891. Doing it this way will also solve the problem that arises when self modifying
  1892. files are used with things like foreign languages, overlays, PkLite etc. 
  1893. Special foreign language editions are simply made just by providing a specific
  1894. file for that language.
  1895.  
  1896. To create the file just create a typed file of string[80] and use record zero
  1897. as a header in which you can store data such as random number generator seeds,
  1898. passwords etc.  All this is very simple to do.  Here is a simple program to
  1899. encrypt such a file and the function to place in the program to unencrypt
  1900. the respective string.  It is by no means unbreakable but will certainly represe
  1901. t more trouble to work out what you are doing than it is worth!
  1902.  
  1903. {$X+}
  1904. program encrypt;
  1905. uses crt;
  1906. var f        : file of string[80];
  1907.     txt      : text;
  1908.     st       : sting[80];
  1909.     key      : longint;
  1910.     SavedKey : longint absolute st;
  1911.  
  1912. procedure EncryptStr(var st: string[80]);
  1913.   var x : byte;
  1914.   begin
  1915.     for x := 1 to length(st) do
  1916.       st[x] := char(st[x] xor random(256);
  1917.   end;
  1918.  
  1919. begin
  1920.   Randomize;
  1921.   assign(f,'TheFile.cfg');
  1922.   rewrite(f);
  1923.   assign(txt,'RawText.txt');
  1924.   reset(f);
  1925.   writeln('Press any key to continue...');
  1926.   repeat
  1927.     key := key xor Random(MaxInt) * Random(MaxInt);
  1928.   until Keypressed;
  1929.   SavedKey := key;
  1930.   RandSeed := key;
  1931.   write(f,st);
  1932.   repeat
  1933.     ReadLn(txt,st);
  1934.     EncryptStr(st);
  1935.     write(f,st);
  1936.   until eof(txt);
  1937.   close(f);
  1938.   close(txt);
  1939. end.
  1940.  
  1941. Untested.
  1942.  
  1943. To unencrypt just read the first 4 bytes of the first record into a longint,
  1944. use that longint as your RandomSeed and then use the above Encrypt procedure
  1945. to unencrypt the string.
  1946.  
  1947. TeeCee
  1948.  
  1949. --- TC-ED   v2.01  
  1950.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1951.  * Tossed by SFToss v1.00b on 92/05/02  15:11:52
  1952.